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(54) Abstract Title 

Diagnostic tool for process control system 

(57) A diagnostic tool 52 for use in a process control 
system with a multiplicity of function blocks, devices or 
loops 36, 40. The tool automatically communicates 
regularly with each block, device or loop, and collects 48 
and stores data indicative of a variability parameter, a 
mode parameter, a status parameter or a limit parameter 
associated with each of the different blocks, devices or 
loops. The collected data is analysed to determine which 
devices, loops or function blocks have problems that 
result in reduced performance of the process control 
system, and a list of detected problems is displayed 14 to 
an operator. The diagnostic tool may then suggest the use 
of other, more specific diagnostic tools to further pinpoint 
or correct the problems. When the diagnostic tool 
recommends and executes a data intensive application as 
the further diagnostic tool, it automatically configures a 
controller 13 of the process control network to collect the 
data needed for such 3. tool. 
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I- 

DIAGNOSTICS IN A 
PROCESS CONTROL SYSTEM 

HELD OF TTTF INVENTION 

The present invention relates generally to process control systems and, more 

5 particularly, to the automatic detection of problems existing within function blocks, 

devices and loops of a process control system. 

DESCRIPTION OF THF RELATED ART 

Process control systems, like those used in chemical, petroleum or other 

processes, typically include a centralized process controller communicatively 

10 coupled to at least one host or operator workstation and to one or more field devices 

via analog, digital or combined analog/digital buses. The field devices, which may 

be, for example valves, valve positioners, switches and transmitters (e.g., 

temperature, pressure and flow rate sensors), perform functions within the process 

such as opening or closing valves and measuring process parameters. The process 

15 controller receives signals indicative of process measurements made by the field 

devices and/or other information pertaining to the field devices, uses this 

information to implement a control routine and then generates control signals which 

are sent over the buses to the field devices to control the operation of the process. 

Information from the field devices and the controller is typically made available to 

20 one or more applications executed by the operator workstation to enable an operator 

to perform any desired function with respect to the process, such as viewing the 

current state of the process, modifying the operation of the process, etc. 

In the past, conventional field devices were used to send and receive analog 

(e.g., 4 to 20 milliamp) signals to and from the process controller via an analog bus 

25 or analog lines. These 4 to 20 ma signals were limited in nature in that they were 

indicative of measurements made by the device or of control signals generated by 

the controller required to control the operation of the device. However, in the past 

decade or so, smart field devices including a microprocessor and a memory have 

become prevalent in the process control industry. In addition to performing a 

30 primary function within the process, smart field devices store data pertaining to the 

device, communicate with the controller and/or other devices in a digital or 
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combined digital and analog format, and perform secondary tasks such as self- 
calibration, identification, diagnostics, etc. A number of standard and open smart 
device communication protocols such as the HART®, PROHBUS®, WORLDFIP* 
Device-Net*, and CAN protocols, have been developed to enable smart field 
5 devices made by different manufacturers to be used together within the same 
process control network. 

Moreover, there has been a move within the process control industry to 
decentralize process control functions. For example, the all-digital, two-wire bus 
protocol promulgated by the Fieldbus Foundation, known as the Foundation™ 
10 Fieldbus (hereinafter "Fieldbus") protocol uses function blocks located in different 
field devices to perform control operations previously performed within a 
centralized controller. In particular, each Fieldbus field device is capable of 
including and executing one or more function blocks, each of which receives inputs 
from and/or provides outputs to other function blocks (either within the same device 
15 or within different devices), and performs some process control operation, such as 
measuring or detecting a process parameter, controlling a device or performing a 
control operation, such as implementing a proportional-derivative-integral (PID) 
control routine. The different function blocks within a process control system are 
configured to communicate with each other (e.g., over a bus) to form one or more 
20 process control loops, the individual operations of which are spread throughout the 
process and are, thus, decentralized. 

With the advent of smart field devices, it is more important than ever to be 
able to quickly diagnose and correct problems that occur within a process control 
system, as the failure to detect and correct poorly performing loops and devices 
25 leads to sub-optimal performance of the process, which can be costly in terms of 
both the quality and the quantity of the product being produced. Many smart 
devices currently include self-diagnostic and/or calibration routines that can be used 
to detect and correct problems within the device. For example, the FieldVue and 
ValveLink devices made by Fisher Controls International Inc. have diagnostic 
30 capabilities that can be used to detect certain problems within those devices and also 



have calibration procedures that can be used to correct problems, once detected. 
However, an operator must suspect that a problem exists with the device before he 
or she is likely to use such diagnostic or calibration features of the devices. There 
are also other process control tools, such as auto-tuners that can be used to correct 
poorly tuned loops within a process control network. Again, however, it is 
necessary to identify a poorly operating loop before such auto-tuners can be used 
effectively. Similarly, there are other, more complex, diagnostic tools, such as 
expert systems, correlation analysis tools, spectrum analysis tools, neural networks, 
etc. which use process data collected for a device or a loop to detect problems 
therein. Unfortunately, these tools are data intensive and it is practically impossible 
to collect and store all of the high speed data required to implement such tools on 
each process control device or loop of a process control system in any kind of 
systematic manner. Thus, again, it is necessary to identify a problem loop or a 
device before being able to effectively use these tools. 

Still further, each device or function block within a smart process control 
network typically detects major errors that occur therein and sends a signal, such as 
an alarm or an event, to notify a controller or a host device that an error or some 
other problem has occurred. However, the occurrence of these alarms or events 
does not necessarily indicate a long-term problem with the device or loop that must 
be corrected, because these alarms or events may be generated in response to (or be 
caused by) other factors that were not a result of a poorly performing device or 
loop. Thus, the fact that a device or a function block within a loop generates an 
alarm or event does not necessarily mean that the device or loop has a problem that 
needs to be corrected. On the other hand, many devices can have problems without 
the problem rising to the level of severity to be detected as an alarm or an event. 

To initially detect problems within the process control system, a process 
control operator or technician generally has to perform a manual review of data 
generated within a process control system (such as alarms and events, as well as 
other device and loop data) to identify which devices or loops are operating sub- 
optimally or are improperly tuned. This manual review requires the operator to 



have a great deal of expertise in detecting problems based on raw data and, even 
with such expertise, the task can be time-consuming at best and overwhelming at 
worst. For example, an instrumentation department of even a medium-sized 
operating plant may include between 3,000 and 6,000 field devices such as valves 
and transmitters. In such an environment, the instrument technician or control 
engineer responsible for a process area simply does not have the time to review the 
operation of all the field device instrumentation and control loops to detect which 
loops or devices may not be operating properly or may have some problem therein. 
In fact, because of limited manpower, the only devices usually scheduled for 
maintenance are those that have degraded to the point that they dramatically impact 
the quantity or quality of the product being produced. As a result, other devices or 
loops which need to be retuned or which otherwise have a problem therein that 
could be corrected using the tools at hand are not corrected, leading to the overall 
degraded performance of the process control system. 

cttmmarV OF THE INVENTION 
A diagnostic tool for use in a process control system automatically collects 
and stores data pertaining to the different function blocks of devices and loops 
within the system, processes that data to determine which function blocks, devices, 
or loops have problems that may result in the reduced performance of the process 
control system, and then may suggest the use of other, more specific diagnostic 
tools to further analyze and correct the problem. The diagnostic tool may detect 
problems or identify poorly performing devices or loops using a variability 
indication, a mode indication, a status indication or a limit indication associated 
with each of the function blocks or devices within a process control system. The 
variability indication is preferably determined or partially determined by each 
function block within the process control system to provide a statistical 
measurement of the deviation of a parameter associated with the device or function 
block from a set point or other value associated with the device or function block. 
The mode indication identifies the mode in which a function block or device is 
operating, e.g., a normal mode or a non-normal mode, to indicate if the device or 



function block is operating in its designed mode. The status indication identifies the 
quality of a signal associated with the function block or device at any given time. 
The limit indication may identify if a function block signal is limited in nature. 

The diagnostic tool may determine which function blocks, devices or loops 
have problems associated therewith based on the instantaneous values or on a 
compilation of the historical values of one or moire of the variability indication, the 
mode indication, the status indication, the limit indication or other data associated 
with each function block or device. Thereafter, the diagnostic tool may report 
detected problems to an operator via a display screen and/or may generate written 
reports (such as printed reports) or electronic reports sent, for example, over the 
internet (e.g., through E-mail) to concerned persons. 

Furthermore, upon detecting problems within one or more process control 
devices or loops, the diagnostic tool may suggest the proper tool(s) to be used to 
further pinpoint the problem and/or to correct the detected problem. If requested to 
do so, the diagnostic tool executes these further tools on a host workstation to 
enable an operator to perform further diagnostic functions. In cases where the 
diagnostic tool requires the use of further data intensive tools to diagnose or 
pinpoint a specific problem (such as an expert system or a correlation analysis tool), 
the diagnostic tool may automatically configure the host system to collect the data 
needed to run that further tool. 

In this manner, the diagnostic tool identifies the function blocks, devices, 
loops, etc. which need attention without requiring an operator to review massive 
amounts of data pertaining to numerous devices and loops within a process control 
system. This saves time on the part of the operator and does not require the 
operator to have a great deal of expertise in detecting problem loops and devices. 
Also, upon detecting a problem, the diagnostic tool may recommend the use of 
further tools to pinpoint and/or correct the problem, which enables the operator to 
correct problems without having to guess as to which tool is the most appropriate in 
any given situation. Besides saving time, this function reduces the burden on the 
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operator and helps to assure that the proper diagnostic tools are used in each 
circumstance. 

pprp p BESCRE HQH OF TfF EE a WINGS 
Fig. 1 is a block diagram of a process control system in which a diagnostic 
tool can be used; 

Fig. 2 is a block diagram of a process control system of Fig. 1 illustrating 
the configuration of two process control loops run in conjunction with a diagnostic 
tool; 

Fig. 3 is a block diagram of a function block having a variability indication 
generator therein; 

Fig. 4 is a block diagram of a routine implemented by a diagnostic tool to 
perform diagnostics in the process control system of Figs. 1 and 2; 

Fig. 5 is a first example screen display generated by the diagnostic tool used 
in the process control system of Figs. 1 and 2; 

Fig. 6 is a second example screen display generated by the diagnostic tool 
used in the process control system of Figs. 1 and 2; 

Fig. 7 is a third example screen display generated by the diagnostic tool 
used in the process control system of Figs. 1 and 2; and 

Fig. 8 is a block diagram of the controller and operator workstation of Figs. 
1 and 2, illustrating trending communications associated with a diagnostic tool. 
pfSPPTPTTON OF TOT PRFFFRRFT) EMBODIMENTS 
Referring now to Fig. 1. a process control system 10 includes a process 
controller 12 connected to a host workstation or computer 13 (which may be any 
type of personal computer or workstation) having a display screen 14 and connected 
to field devices 15-22 via input/output (I/O) cards 26 and 28. The controller 12, 
which may be by way of example, the DeltaV™ controller sold by Fisher- 
Rosemount Systems, Inc., is communicatively connected to the host computer 13 
via, for example, an ethemet connection and is communicatively connected to the 
field devices 15-22 using any desired hardware and software associated with, for 
example, standard 4-20 ma devices and/or any smart communication protocol such 



as the Fieldbus protocol. The controller 12 implements or oversees a process 
control routine stored therein or otherwise associated therewith and communicates 
with the devices 15-22 and the host computer 13 to control a process in any desired 
manner. 

5 The field devices 15-22 may be any types of devices, such as sensors, 

valves, transmitters, positioners, etc. while the I/O cards 26 and 28 may be any 
types of I/O devices conforming to any desired communication or controller . ? 
protocol. In the embodiment illustrated in Fig. 1, the field devices 15-18 are 
standard 4-20 ma devices that communicate over analog lines to the I/O card 26 

10 while the field devices 19-22 are smart devices, such as Fieldbus field devices, that 
communicate over a digital bus to the I/O card 28 using Fieldbus protocol 
communications. Generally speaking, the Fieldbus protocol is an all-digital, serial, 
two-way communication protocol that provides a standardized physical interface to 
a two-wire loop or bus that interconnects field devices. The Fieldbus protocol 

15 provides, in effect, a local area network for field devices within a process, which 
enables these field devices to perform process control functions (using function 
blocks) at locations distributed throughout a process facility and to communicate 
with one another before and after the performance of these process control functions 
to implement an overall control strategy. It will be understood that, while the 

20 Fieldbus protocol is a relatively new all-digital communication protocol developed 
for use in process control networks, this protocol is known in the art and is 
described in detail in numerous articles, brochures and specifications published, 
distributed, and available from, among others, the Fieldbus Foundation, a not-for- 
profit organization headquartered in Austin, Texas. As a result, the details of the 

25 Fieldbus communication protocol will not be described in detail herein. Of course, 
the field devices 15-22 could conform to any other desired standard(s) or protocols 
besides the Fieldbus protocol, including any standards or protocols developed in the 
future. 

The controller 12 is configured to implement a control strategy using what 
30 are commonly referred to as function blocks, wherein each function block is a part 
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(e.g., a subroutine) of an overall control routine and operates in conjunction with 
other function blocks (via communications called links) to implement process 
control loops within the process control system 10. Function blocks typically 
perform one of an input function, such as that associated with a transmitter, a 
5 sensor or other process parameter measurement device, a control function, such as 
that associated with a control routine that performs PID, fuzzy logic, etc. control, 
or an output function which controls the operation of some device, such as a valve, 
to perform some physical function within the process control system 10. Of course 
hybrid and other types of function blocks exist. Function blocks may be stored in 

10 and executed by the controller 12, which is typically the case when these function 
blocks are used for, or are associated with standard 4-20 ma devices and some types 
of smart field devices, or may be stored in and implemented by the field devices 
themselves, which is the case with Fieldbus devices. While the description of the 
control system is provided herein using function block control strategy, the control 

15 strategy could also be implemented or designed using other conventions, such as 
ladder logic. 

The left side of the controller 12 illustrated in Fig. 2 includes a schematic 
representation of interconnected function blocks 30, 32, and 34 making up an 
example process control loop 36 configured to use the standard 4-20 ma devices 17 

20 and 18. Because the function blocks 30, 32 and 34 are related to the operation of 4- 
20 ma devices, these function blocks are stored in and executed by the controller 
12. In a preferred embodiment, in which a DeltaV controller is used, the function 
blocks 30, 32 and 34 are configured to be similar to, that is, to use the same or 
similar protocol, as Fieldbus function blocks. However, this convention is not 

25 necessary as other function block configurations could be used instead. As 

illustrated in Fig. 2, the function block 30 is an analog input (AI) function block 
that provides a measurement made by, for example, the transmitter (sensor) device 
17, to the function block 32. The function block 32 is a PID function block that 
performs calculations using any desired PID strategy and delivers a control signal 

30 via a link to the function block 34, which is preferably an analog output (AO) 



function block. The AO function block 34 communicates with, for example, the 
valve device 18 to cause the valve 18 to open or close according to the control 
signal from the PID function block 32. The AO function block 34 also delivers a 
feedback signal, which may be indicative of the position of the valve 18, to the PID 
function block 32, which uses this feedback signal to generate the control signal. 
The controller 12 includes a device interface 38 (which may be implemented in the 
controller 12 or in the I/O device 26 of Fig. 1) to communicate with the devices 15- 
18 to get measurements made thereby and to deliver control signals thereto 
according to the control loop 36 or other control loops. The device interface 38 
systematically receives signals from the devices 15-18 and delivers these signals to 
the proper function block within the controller 12 associated with the sending 
device. Likewise, the device interface 38 systematically delivers control signals 
from function blocks within the controller 12 to the proper field device 15-18. 

The right side of the controller 12 in Fig. 2 illustrates a sample control loop 
40 implemented using Fieldbus function blocks 42, 44 and 46 located down within 
the Fieldbus field devices 19 and 22. In this instance, the actual function blocks 42, 
44, and 46 are stored in and executed by the field devices 19 and 22 and 
communicate their associated attributes to shadow function blocks 42S, 44S and 46S 
(illustrated as dotted-line boxes) within the controller 12. The shadow function 
blocks 42S, 44S and 46S are set up according to the function block configuration 
used by the controller 12 but mirror the state of the actual function blocks 42, 44 
and 46, respectively, so that it appears to the controller 12 that the actual functions 
associated with the function blocks 42, 44 and 46 are being executed by the 
controller 12. The use of shadow function blocks within the controller 12 enable 
the controller 12 to implement a control strategy using function blocks stored in and 
executed within the controller 12 as well as within field devices. Of course, the 
controller 12 can implement control loops having both standard function blocks 
(like function blocks 30, 32 and 34) and shadow function blocks therein. For 
example, the PID shadow function block 44S, associated with the actual function 
block 44 in the valve positioner 22, could be linked to the AI function block 30 and 



the AO function block 34 to form a process control loop. The creation and 
implementation of shadow function blocks is not the subject of the present invention 
and is described in more detail in U.S. Patent Application Serial No. 09/151,084 
entitled "A Shadow Function Block Interface for Use in a Process Control 
Network," filed September 10, 1998, which is assigned to the assignee of the 
present invention and the disclosure which is hereby expressly incorporated by 
reference herein. 

In one embodiment of the present invention, the controller 12 includes a 
diagnostic data collection unit 48 which may be, for example, a short term memory 
that collects and stores certain kinds of data associated with each of the function 
blocks (or shadow function blocks) of the process control system 10 for use in 
detecting problems with those function blocks, or the devices or loops associated 
with those function blocks. The data collection unit 48 may, for example, collect 
and store a variability indication, a mode indication, a status indication and/or a 
limit indication for each of the function blocks within the process control network 
10. If desired, the data collection unit 48 may perform some processing on the 
collected data as described below. The data collection unit 48 periodically sends the 
collected or processed data to the operator workstation 13 via the ethernet 
connection for storage in a long term memory or historian 50 and for use by a 
diagnostic tool 52 located at least partially within the operator workstation 13. The 
diagnostic tool 52, which is preferably implemented in software stored in a memory 
of the operator workstation 13 and executed by a processor 54 of the operator 
workstation 13, detects problems within the process control system 10, reports these 
problems and suggests tools for use in further analyzing and correcting these 
problems. If desired, portions of the diagnostic tool software can be executed 
within the controller 12 or even within the field devices. 

The diagnostic tool 52 systematically detects problems using one or more 
operating parameters of the function blocks or devices within the process control 
system 10 including, for example, a variability parameter, a mode parameter, a 
status parameter and a limit parameter determined by (or associated with) each of 

-10- 



the function blocks or devices within the process control network 10. An indication 
of the variability parameter can be calculated or otherwise determined for each 
device or function block within the process control system (whether those ftinction 
blocks are implemented within the controller 12 or down within one of the field 
devices 19-22) to indicate the error between two parameters of the ftinction block. 
These two parameters may be different signals associated with the function block or 
may be two different measurements of the same signal. For example, for AI 
ftinction blocks, the variability indication may indicate the error between a 

statistical measure (such as the mean, median, etc.) of the measurement made by a 

( 

sensor over a predetermined amount of time and the actual or instantaneous value of 
the measurement. Similarly, for an AO function block, the variability indication 
may be calculated based on the differences between a historical statistical state of a 
device over a predetermined amount of time (such as the average location of the 
valve in a valve device) and the current state of the device (such as the current 
location of the valve). For control function blocks, such as PID, ratio, fiizzy logic 
ftinction blocks and the like, the variability indication may be based on a deviation 
of a process parameter input to the function block and a set point or target provided 
to the function block for that parameter. 

In one embodiment, a variability index may be determined as the integrated 
absolute error (IAE) over a particular interval, such as a ten minute evaluation 
period. In such a case, the variability index can be calculated as: 

i«l iv 

wherein: N = the number of samples in the evaluation period; 
X(i) = the value of the ith sample of the desired 

ftinction block parameter, such as the input to 
the function block for AI blocks and control 
blocks; and 



S = the statistical or target value of the parameter .. 
to which the function block parameter is 
compared, e.g., the set point (for control 
blocks), the average value of the function block 
parameter over the last evaluation period (for 
AI blocks), etc. 

If the variation between the X and S variables of equation (1) is Gaussian in nature, 
then the IAE is equal to the standard deviation times the square root of the product 
of two over pi. Of course, any other variability indication could be used in addition 
to or instead of the IAE calculation described above and, thus, the variability 
indication is not confined to that of equation (1). 

Preferably, each function block, and especially those located within the field 
devices 19-22, automatically calculates a variability indication over each evaluation 
period (e.g., over a predetermined amount of time or number of execution cycles) 
and, after each evaluation period, sends the calculated variability indication to the 
data collection device 48 within the controller 12 or to the data historian 50 within 
the operator workstation 13. This variation indication may be, for example, the 
variability index given above or may be subparts thereof which can be used to 
determine the variability index given above. If the function blocks are Fieldbus 
function blocks located within one of the field devices 19-22, then the variability 
indication may be sent to the controller 12 using asynchronous communications. 
While the final variability index for each function block could be completely 
calculated by the controller 12 or the operator workstation 13, this would require 
each function block to send data to such devices after every execution cycle 
(typically on the order of every 50-100 milliseconds), which would require a lot of 
additional communications over the buses of the process control network 10. To 
eliminate this additional communication, it is preferable to design each function 
block to calculate a variability indication therefor and then send this variability 
indication over the communication buses once every evaluation period, which will 
typically be on the order of once every minute, ten minutes or more. Currently, no 
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known standard function blocks provide this capability and, therefore, it should be 
added to the function blocks used within the process control system 10. 

In one embodiment, the calculations for a final variability index associated 
with a function block are split between the function block and the diagnostic tool 
52. In particular, because the computation of the variability index takes computing 
resources, the most computationally consuming parts of these calculations are done in 
the workstation 13 or the controller 12. For this discussion, the calculations for a 
variability index for input and output blocks will be referred to simply as a 
variability index (VI) while the variability index for control function blocks will be 
referred to as a control index (CI). The VI (which is used for input blocks, output 
blocks and control blocks in manual mode) and the CI (which is used for control 
blocks in auto mode) can be calculated by the workstation 13 or the controller 12 as 
follows: 



vi = i- 



S +s 

S *S 
tot 



(2) 



15 



CI = 1- 



S +s 

S +S 
tot 



(3) 



20 



wherein: 



s 



minimum standard deviation expected with feedback 
control; 

actual measured standard deviation; and 

sensitivity factor used to make the calculations stable. 



S, q may be calculated as: 



s = s 

Jq capah 



2 - 



capab 



(4) 



wherein: 
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Scapab - estimated capability standard deviation (standard 
deviation at process ideal operation). 
A small bias value s is added to the and S toe values in equations (2) and 
(3) because it has been discovered that, if the disturbance to noise signal ratio (i.e., 
5 the low frequency to high frequency disturbance ratio) is too high, the VI and CI 
calculations give too high of values. Fast sampling with very small differences 
between consecutive measurements also attributes to this problem. The bias value 
s, it has been found, makes the computations stable. The recommended bias value s 
is 0.1 % of the measurement range (approximately the measurement accuracy). It 
10 will be understood that a valve of zero for the VI or CI calculations of equations (2) 
and (3) is the best case while a value of one is the worst case. However, these or 
other variability indices could be calculated so that a value of one (or even some 
other value) is the best case. 

If desired, a percent improvement (PI) value can be established for the 
15 control blocks as 100 times the CI value for the control block. 

To perform the above VI, CI and PI calculations in the most efficient manner 
possible, each of the function blocks in, for example, the DeltaV environment or the 
Fieldbus environment may calculate the and S wt values as variability indications 
and make these values visible to the controller 12, which can then calculate the VI and 
20 CI values using equations (2) and (3) or can provide the and S tol values to the 
diagnostic tool 52 in the workstation 13 which can calculate the VI and CI values. 
The intermediate calculations needed to determine the S afab and values will be 
performed each execution of the function block and the and S lot values will be 
updated once every N executions of the function block (i.e., once every evaluation 
25 period). In one implementation, the S capab and S w values may be updated after 100 
executions of the function block. 

The total standard deviation S wt can be calculated in the function block using 
the so-called moving time window computation as follows: 

S tol — 1 .25 MAE (5) 
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wherein MAE is the mean absolute error calculated as: 



mw= ± S|(y(t)-y | (6) 



and wherein: 

N = the number of executions in an evaluation 
period; 

y(t) = the value of the t'th instantaneous sample of the 
desired function block parameter, such as the 
input to the function block; and 

y st = the statistical or target value of the parameter 
to which the function block parameter is 
compared, e.g., the average or mean value of 
the function block parameter over the last 
evaluation period. 

Generally speaking, the process value (PV) of the function block will be used 
in the I/O blocks to calculate y $t . In control blocks, either the working setpoint or the 
PV will be used as y st depending on the block mode. 

The capability standard deviation, S^^, can be calculated as follows: 



5 * (7) 

capab 1.128 V ' 



wherein MR is the average moving range, which may be calculated as: 

«R = t^t £|(y<e)-y<t-i)>| (8) 
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To reduce computations, only the summing component associated with the 
MAE and MR will be done during each execution cycle of the function block. The 
division of the sum by N or N-I can be done as part of the S t0 , and calculations 
once every N executions (i.e., once every evaluation period). From the above 
formulas it is evident that: 



S - 1.25 • — • Error 

tot N ' 



1 - (9) 



s 



-L- » Delta 

* b l (10) 



cmp*b 1.128 



wherein the Error^ and the Delta^ are the summations in equations (6) and (8) 
respectively and are calculated on an ongoing basis during each execution cycle of 

10 the function block. 

Of course, the quality of the input to the function block used in these 
calculations is important and, thus, it is desirable to only use data that has good 
status and data that is not limited. When using Fieldbus or DeltaV function blocks, 
the mode variable takes the status of the PV, set point and BackCalibration 

15 variables into account, and so the mode variable can be used to assure proper 
calculations for the variability index. For example, in the OOS (out of service) 
mode, the S t « and variables are not determined but are, instead, set to the best 
case valve (e.g., zero) to prevent the detection of an error. On warm starts, if the 
mode changes from OOS to any other mode, the S lol and variables can be set 

20 to zero (a best case value), the scan counter can be reset and the Error 4b$ and Data^ 
variables of equations (9) and (10) can be set to zero. Also, the previous values of 
y and y R should be reset. 

Fig. 3 illustrates a function block 55 having an input 56, an output 57 and a 
variability indication generator 58 connected to the input 56. If desired the 

25 variability indication generator 58 may be additionally or alternatively connected to 
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the output 57 and/or to other parts of the function block 55 to receive other function 
block parameters or signals (these connections being illustrated by dotted lines in 
Fig. 3). If the function block 55 is, for example, a control function block, the 
variability index calculator 58 receives the input 56 (which may be the process 
value that is being controlled by the loop in which the control block 55 operates) 
and compares that input to a set point previously supplied to the function block 55. 
The variability indication generator 58 may determine the variability index 
according to equation (1) and send that index to a communicator 59 which sends the 
variability indication to the controller 12 every evaluation period (every N samples). 
However, as described above, the variability indication generator 58 may determine 
the S^, and S capab values in the manner described above and send these values to the 
controller 12 or workstation 13, which can determine the VI and/or CI values 
therefrom If the function block 55 is a function block being executed within the 
controller 12, the controller 12 could include a separate routine to determine the 
variability indication for each function block, as no bus communications would need 
to take place after each sample interval. The communicator 59 can be any standard 
communication unit associated with a function block or a communication protocol. 

A second function block operating parameter that may be used to determine 
problems within the process control system 10 is an indication of the mode in which 
each of the function blocks (or loops or devices) is operating. In the case of 
Fieldbus function blocks, as well as some other known function blocks, each 
function block has a mode parameter that is available to the controller 12 to indicate 
the mode in which the function block is operating. From this mode indication, a 
data analyzer within the diagnostic tool 52 can determine a value of the mode 
parameter to indicate if the function block (and thereby the loop, module or device) 
is operating in its desired or designed mode or, alternatively, if something has 
occurred to cause the function block (device or loop) to operate in a different, less 
preferable mode. Fieldbus function blocks operate in one of a number of modes. 
For example, AI function blocks operate in an out-of-service mode (wherein an 
operator may have put the device out-of-service to perform maintenance), a manual 

- 17- 



mode in which some signal, such as an output of the function block, is being set 
manually instead of based on the designed operation of the function block, and an 
automatic mode, in which the function block is operating in a normal manner, i.e., 
the way in which it was designed to operate. Fieldbus control blocks can also have 
one or more cascade modes wherein the mode is controlled by other function blocks 
or by an operator. Typically, Fieldbus function blocks have three modes variables 
associated therewith at any given time including a target mode, which is the mode 
in which the operator has set the block to operate (which can be other than the 
normal or automatic mode), an actual mode, which is the mode in which the control 
block is actually operating at any given time, and a normal mode, which is the 
mode in which the function block was designed to operate and is associated with the 
normal operation of the function block. Of course, these or other mode indications 

may be used as desired. 

The mode indication may be periodically provided to the controller 12 
and/or to the operator workstation 13. If the function block is within the controller 
12, the mode indication for each function block may be provided to the data 
collection unit 48 at any desired time or interval. For Fieldbus function blocks or 
other function blocks within the field devices, the controller 12 may periodically 
request the mode parameters for each function block using a ViewList request (in 
the Fieldbus protocol). If desired, the data collection unit 48 within the controller 
12 may store the mode at each sampling period or evaluation period and provide the 
stored data to the data historian 50. Thereafter, the diagnostic tool 52 may 
determine mode values indicating when or how long the function block spent in the 
different modes or in a normal mode (or a non-normal mode) or indicating what 
percent of a specific time period the function block was in a normal mode (or a non- 
normal mode). Alternatively, the data collection unit 48 or some other specifically 
designed unit within the controller 12 could detect when each function block is out 
of its normal mode (by, for example, comparing the function block's normal mode 
with its actual mode at any given time). In this case, the data collection unit 48 
could communicate the mode of any function block by indicating when changes in 
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the mode took place or are detected , which reduces the amount of communication 
needed between the controller 12 and the operator workstation 13. 

A status parameter is another function block operating parameter that may 
be used to detect problems within process control devices and loops. A status 
indication provided by each function block may define or identify the status of the 
primary value (PV) associated with the function block or device. In addition or 
alternatively, one or more of the inputs and outputs of a function block may have a 
status indication associated therewith. Fieldbus function blocks have a status 
parameter associated therewith which can take on the form of "good", "bad" or 
"uncertain" to indicate the status of the function block PV, inputs and/or outputs. A 
status indication may also identify or include a limit indication, such as the limits 
associated with the PV or other function block parameter. Thus, for example, the 
limit indication may indicate whether the PV of the function block is high or low 
limited. Again, the diagnostic tool 52 may determine status values or limit values 
indicating when, how long or what percent of a specific time period the status of the 
function block was a normal status (or a non-normal status), and when, how long or 
what percent of a specific time period a function block variable was at one or more 
limits (or not at the one or more limits), or was a bad status or a questionable 
status. 

Similar to the mode indication, the status indication and the limit indication 
may be sent by each function block to the controller 12 periodically or on request 
(using, for example, the ViewList command in the Fieldbus protocol) and changes 
therein may determined by the controller 12 and sent to the operator workstation 
13. Alternatively, the status and limit indications may be sent to the operator 
workstation 13 without being processed. If desired, the function blocks may be set 
up to communicate mode, status and/or limit indications only when changes therein 
actually take place, which further reduces the amount of communications between 
the controller 12 and the function blocks within field devices. However, when 
using this communication scheme, the current state of all the required parameters is 
needed to establish a base against which to compare the changes when the 
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diagnostic tool 52 is first placed on line. This current state may be measured or 
collected by having the controller 12 periodically report parameter values (even 
though they have not changed) or by having the diagnostic tool 52 cause the 
controller 12 to report parameters defined for exception reporting. Based on the 

5 status of each of the function blocks, the diagnostic tool 52 can quickly identify 
measurements which are bad, and need attention (uncertain status) or which have 
been incorrectly calibrated because they have a measurement or PV that is limited. 
Of course, the status and limit indications may take on one of any different number 
and types of values, depending on the type of system in which they are being used. 

10 Furthermore, a status indication may be used for any different variables 

(other than the PV) of a function block, device or loop. For example, in a control 
loop having feedback control, the status of the feedback variable may be used to 
detect problems within function blocks and loops. The status of this feedback 
variable (e.g., the back calibration or BackCal variable for control or actuator 

15 function blocks in the Fieldbus protocol), or any other variable, can be examined by 
the diagnostic tool 52 to detect when a function block has an output that is limited 
by V for example, a downstream function block or other downstream condition. 
Similar to the mode indication, the controller 12 may detect and store actual status 
values or may store changes in the status values as the status indication. 

20 Other data associated with a process control function block, device or loop 

may be used to detect problems as well. For example, the operator workstation 13 
(or the controller 12) may receive, store and review events and alarms generated by 
the devices or function blocks within the process control network 10. In, for 
example, the Fieldbus environment, function blocks support a block error parameter 

25 that reports abnormal processing conditions detected by a transducer or a function 
block. Fieldbus devices reflect any problem that is detected by the device or 
function block using one of 16 defined bits in a block error bitstream sent to the 
controller 12. Fieldbus devices report the first detected problem to the controller 
12 as an event or alarm and these events or alarms can be forwarded by the 

30 controller 12 to an operator workstation 14 event journal. In one embodiment, the 
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diagnostic tool 52 analyzes or reviews the 6th bit of the block error parameter (in 
the Fieldbus protocol) to detect when a device needs maintenance soon and, thus, 
when a condition exists that must be addressed but which is not currently limiting 
device operation. Similarly, the diagnostic tool 52 analyzes the 13th bit of the 
5 block error parameter (in the Fieldbus protocol) to determine when correct device 
operation is not possible because of a condition detected by the device and, thus, 
immediate action is required. Of course, other events, alarms, other bits within the 
block error parameter or other types of error indications may be used by the 
diagnostic tool 52 to detect problems associated with the operation of the process 
10 control network 10, and such other events, alarms etc. may be associated with the 
Fieldbus protocol or any other desired device or controller protocol. 

In some instances, function blocks may have parameters, such as mode or 
status parameters that are set to other than normal or good for reasons unrelated to 
the correct operation of the process or loop in which these function blocks operate. 
15 For example, in batch processes, when a batch is not being run, the modes of the 
function blocks used within that process are set to non-normal values. However, it 
would be undesirable to detect these non-normal mode (or status) indications and 
identify problems with the system based thereon because the batch process is 
designed to have down times. It is preferable, therefore, to provide each function 
20 block (or the module or loop in which it is run) with an application state parameter 
indicating if the function block (or module) is purposely in a non-normal mode, or 
has a bad status. In other words, the application state parameter will indicate when 
alarming or problem detection for the function block should be prevented. For 
function blocks used in batch processes, for example, the application state 
25 parameter will be set to one value to indicate when the function blocks are operating 
to perform a batch run application and will be set to another value to indicate when 
the function blocks are purposely not being used to perform a normal function 
within a batch run application and so no detection of problems should be based on 
the operations of these function blocks at these times. Such an application state 
30 parameter is illustrated in Fig. 3 to be communicated to the controller 12 via the 
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communicator 59. The controller 12 and/or operator workstation 13 may detect the 
application state parameter for each function block and ignore data (such as 
variability, mode, status and limit data) associated with function blocks that are in 
the second category, e.g., that are purposely set to non-normal or bad states, in 
order to prevent false alarms. Of course, there are other reasons that the 
application state parameter may be set to prevent detection of problems besides the 
down time associated with batch processes. ^ . 

The diagnostic tool 52 is preferably implemented in software within the 
operator workstation 14 and, if necessary, some parts may be implemented in the 
controller 12 and even down within the field devices, such as the field devices 19- 
22. Fig. 4 illustrates a block diagram of a software routine 60 that may be executed 
in the operator workstation 14 to detect and help correct problem function blocks, 
devices, loops or other entities within the process control network 10. Generally 
speaking, the software routine 60 collects data pertaining to each of the function 
blocks within a process, such as variability indication, mode indications, status 
indications, limit indications, alarm or event information, etc., on an ongoing basis 
as the process is running and detects the existence of problem measurements, 
calculations, control loops, etc. based on the collected data. The software routine 
60 may send a report or create a display listing each detected problem and its 
economic impact on plant operation when configured or requested to do so. When 
viewing a display of the detected problem loops on, for example, the display 14 of 
the operator workstation 13, an operator can select a particular problem for review 
or correction. The software routine 60 then suggests and may automatically 
implement other diagnostic tools to further pinpoint the problem or to correct the 
problem. In this manner, the diagnostic tool 52 processes data generated by the 
function blocks or devices of a process control system, automatically recognizes 
problems based on the data and then suggests and executes other diagnostic tools to 
further pinpoint the cause of the problem and to correct the problem. This saves 
the operator enormous amounts of time and effort in detecting and correcting 
problems within a process control system and also helps to assure that the 
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appropriate diagnostic tools (which may not be totally familiar to the operator) are 
used to correct the problem . 

A block 62 of the routine 60 receives and stores the variability, mode, 
status, limit, alarm, event and other data used to detect problems within devices, 
blocks and loops of the process control system 10 on an ongoing basis, i.e., 
whenever the process is running. Preferably, this data is stored in the data historian 
50 within the operator workstation 13. Alternatively, however, this data could be 
stored in any other desired memory, such an in a memory associated with the 
controller 12. Likewise, this data may be sent to the operator workstation 13 in any 
format and may be sent as compressed data, if so desired. 

A block 63 detects or determines when an analysis of the data is to be 
performed because, for example, a periodic report is to be generated or because a 
user is requesting such an analysis. If no analysis is to be performed, the block 62 
simply continues to collect data and may process that data to determine values for 
the function block operating parameters. If an analysis is to be performed, a block 
64 analyzes the stored data or stored parameter values to determine which function 
blocks, devices or loops may be having problems. Generally speaking, the data 
may be analyzed based on the current or instantaneous values of the function block 
operating parameters, or may be analyzed on a historical basis to determine which 
function blocks, devices or loops are having problems over a specific period of 
time. The historical analysis helps to detect problems that are long term in nature 
based on the performance over a specified period of time. To detect a problem, the 
block 64 may, if necessary, calculate a variability index from the variability 
indications supplied by the function blocks and then compare the variability index to 
a specific range or limit (which may be set by the operator) to see if either the 
instantaneous value of, or some statistical measure of the historical value (such as 
the average or median value) of the variability index is outside of the range or 
above or below the specified limit for a function block. If so, a problem may exist 
and the function block, device or loop associated with the out-of-range variability 
index is listed as having a problem to be corrected. 
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Likewise, the block 64 may compare the actual mode of a function block or 
device with the normal mode of that function block or device to see if they match. 
As indicated above, the controller 12 may perform this function and send 
indications of the result, or of mismatches to the historian 50. If desired, however, 
the operator workstation 13 may perform these comparisons directly. Using the 
historical data, the block 64 may determine loop utilization, i.e., the percent of time 
that the loop (or function block) operated in the designed (normal) mode. In the 
instantaneous analysis, the function block, loop or device may be considered to 
have a problem when it is currently not operating in the designed or normal mode. 

Similarly, the block 64 may analyze the status and limit indications) of each 
function block to determine when the status is bad or uncertain or otherwise not a 
designed or normal status or when a function block signal is at a limit. A historical 
analysis may calculate or determine if a particular function block has a status 
indication that is bad or uncertain for a predetermined percentage of a specified 
amount of time, may determine which PVs or other variables reached a limit or 
stayed at a limit for a predetermined percentage of a specified amount of time, or 
may analyze the status indication or limit indication in any other manner to 
determine if a problem exists within the function block or device or loop in which a 
function block is located. Likewise, the block 64 may determine, in an 
instantaneous evaluation, which function blocks, devices or loops have status values 
that are currently not in the designed or normal state and/or which signals or 
variables have reached a limit (i.e.. are value limited). The block 64 may review 
the alarm and event notifications to see if any devices need maintenance, either now 
or in the future. The blocks which exceed the variability or control index limits and 
the blocks which have an active bad. limited, or mode condition will be identified 
and temporarily saved. This summary information can support the creation of 
"current- summary display. The instantaneous values and conditions can be 
integrated by the diagnostic tool 52 on, for example, an hour, shift and daily basis 
to obtain the average value of variability index and the percent improvement and the 
percent time the bad status, limited signal or non-normal mode condition existed. 
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Of course, the block 64 may perform other types of processing on the variability, 
mode, status, limit, event, alarm and/or any other desired data to detect problems. 
Furthermore, the block 64 may run the analysis using different limits, ranges, 
historical times, etc., all of which may be set by a user or an operator. 

For function blocks used in, for example, batch mode processes, data 
associated with times when a function block intentionally was not operating is 
discarded or not used in the analysis based on the application state parameter for the 
function block. 

After the block 64 has detected the problems within the process control 
network, a block 66 determines if any written or electronic reports should be 
generated because, for example, periodic reports have been requested by a user. If 
so, a block 68 creates a report listing the problem function blocks, devices, loops, 
etc. and their economic effect on the process control system. Such an economic 
impact may be determined by having an operator or other user specify the dollar 
amount associated with each percentage point of reduced operation of the process or 
a loop in the process. Then, when a loop is found to have a problem, the actual 
performance of the process loop may be compared to a known optimum 
performance value to determine the percentage difference. This percentage 
difference is then multiplied by the specified dollar amount to percentage point ratio 
to determine the economic impact in terms of dollars. The report may be printed 
out on a printing device, displayed on a computer screen (such as the display 14) or 
other electronic display, sent to a user via E-mail, the Internet or any other local 
area or wide area network, or may be delivered to a user in any other desired 
manner. If desired, the diagnostic tool 52 may be configured to automatically 
notify a plant maintenance system whenever a problem loop is detected and this 
notification can be sent to the maintenance system as an event using the event/alarm 
capability of the known OPC interface. 

A block 70 determines if an operator has requested an analysis to be 
performed at the workstation 13 and, if so, a block 72 enters a display or dialog 
routine that enables a user to find out different information related to the problem or 
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to select different parameters for performing the analysis. In one embodiment, an 
operator or other person that uses the diagnostic tool 52 is presented with a dialog 
when he or she logs onto the workstation 13. The dialog summarizes the conditions 
that need to be addressed in the system without identifying the loops that are the 
source of the problem. The dialog may convey the information in a graphical 
format such as on screen display 80 as shown in Fig. 5. The screen display 80 
summarizes the percent of total input, output or control function blocks in the 
process or plant that currently violate the default limits set for utilization (mode), 
limited signals, bad status or high variability. Because multiple conditions may 
exist in a single block, the total could potentially exceed 100%. If the total exceeds 
100 percent, then the percent for each category can be scaled so that the total equals 
100 percent. Modules that have input, output, or control blocks that violate the 
preset limits are summarized in a tabular list 82. In Fig. 5, module FIC101 has 
one or more function blocks operating in undesigned modes and one or more 
function blocks with high variability, while the module LIC345 has one or more 
fiinction blocks with bad status. 

More information about the nature of the problems, such as the limits 
associated with the function blocks, can be shown graphically by, for example, 
clicking on a module name within the list 82. Furthermore, by selecting a filter 
button 84 on the screen of Fig. 5, the user may be presented with a dialog allowing 
the user to select a summary time frame, the types of blocks to be included in the 
summary and the limit for each category or block. Such a dialog screen 86 is 
illustrated in Fig. 6, where the limits for the mode, limited, and bad status of input 
blocks are set at 99 percent utilization and where the limit for the variability index 
for input blocks is set at 1 .3. In this case, the percent utilization of a block is 
determined as the percent of a specific time period in which the mode or status is 
normal and a function block signal was not limited. However, the limits could also 
be set as the percent of time that the mode or status was non-normal or a function 
block variable was at a limit, in which case the limits should be set closer to zero. 
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Of course, by choosing all of the loop selections within the screen 86, all modules 
that include an input, output or control block will be included in the summary. 

A Timeframe box 88 of the screen 86 can be manipulated by changing the 
setting therein to alter the. historical time frame for which the analysis is performed. 
5 For example, by choosing a "Now" selection within the Timeframe box 88, the 
instantaneous or current value of the block parameters are used to determine if each 
module will illustrated as a problem module in the summary list 82. While any 
time frame may be specified, some example time frames that can be used in filtering 
are the Current Hour or Last Hour, Current Shift or Last Shift, Current Day or 

10 Last Day, etc. For these time frames, a module is included in the summary list 
only when a detected condition is present for a significant portion (i.e., a 
predetermined portion) of the selected time frame as defined by the limit condition. 

If desired, the user may change the limit values used for variability index, 
either per block or on a global basis. To facilitate setting variability limits, the user 

15 may select the desired limit to be changed and then may be provided with a choice of 
either editing that limit for a particular block or of setting that limit for all of the 
blocks simultaneously. When the user wants to set the variability limit for all of the 
blocks together, the user is presented with a dialog box that allows the variability limit 
to be set to the current value of a variability plus a specified bias provided by the user. 

20 Of course, the limits for variability, mode, status and limited variables may be applied 
to all of the function blocks within a module, an area, a system, or any other logical 
unit and may all be changed in a similar manner. Default limits may be initially 
provided for a configuration as 1.3 for variability index and 99% utilization for mode, 
limited and status indicatioDS._.Of course, these default values may be changed from 

25 the module summary display as described above. 

By selecting a module name within the summary 82 of Fig. 5, the user can 
be provided a dialog screen having further details related to that module. Such a 
dialog screen 90 is illustrated in Fig. 7, for the module FIC101 using the Last Shift 
time frame. The screen 90 illustrates the performance of a PID1 block and an All 

30 block within the FIC101 module. The information provided in the screen 90 allows 
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the user to easily identify the particular measurement, actuator, or control block that 
caused the module to be included in the summary and the percent time that the 
condition was detected. In particular, the percent of time of the last shift that a 
block was in its normal mode, normal status and not limited is illustrated in Fig. 7 
as loop utilization. Of course, the screen of Fig. 7 could be configured to illustrate 
the percent of time during the last shift that a block was in a non-normal mode, or 
had a non-normal status or the percent of time in the last shift that a function block 
variable was at one or more limits. A measure of variation is shown for the blocks 
illustrated in Fig. 7 along with limits therefor. The variability measure in this case is 
calculated so that a value of one is the best case and values greater than one indicate 
more and more variability error. However, using the CI and VI calculations of 
equations (2) and (3) for the variability index will cause the variability index to be 
between zero and one, with zero being the best case. In this case, the variability limit 
should be set to be between zero and one. Furthermore, the percent improvement (PI) 
that is possible in a control loop is illustrated in Fig. 7 for control blocks, namely the 
PID1 block. If desired, the percent utilization values that fall below (or above) the 
respective limits can be highlighted or otherwise marked to indicate the detected 
problem(s). 

Of course, any other screen display may be used to summarize which loops, 
devices, function blocks or measurements have a high variability index (such as 
being greater than a user specified limit), operate in a non-normal mode or have 
process measurements that have bad or uncertain status or that are limited. As 
noted above, using an historical analysis, the diagnostic tool 52 may provide 
displays for a specified time frame to identify devices, loops or function blocks that 
have a variability index, mode, status or limit variable that has changed significantly 
from its normal value. Of course, the diagnostic tool 52 may enable a user to 
choose how many and which tests should be used (and must be failed) before a 
process control condition is identified as having a problem associated therewith. 

Referring again to Fig. 4, when a user selects one of the function blocks in, for 
example, the display 90 of Fig. 7, a block 93 detects the selection of the problem 
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function block and a block 94 displays a set of options to be used to correct the 
problem block or loop. For example, for control blocks, the diagnostic tool 52 may 
allow the user to use an autotuner or other tuner to tune a loop or may allow the user 
to perform trend analysis on the loop. By selecting the autotuner option, the 
diagnostic tool 52 automatically finds and executes the autotuner application for the 
selected control block or loop. However, when the trend option is selected, the 
workstation 13 will begin to collect trending data as describe hereinafter. 

For input or an output function blocks, the block 94 may allow the user to, 
for example, use a further diagnostic tool for that block or to perform trend 
analysis. If, for example, the selected input or output block is within a Fieldbus or 
Hart device, then selecting the diagnostics option will activate the diagnostic 
application for the associated transducer block using tools known in the art such as 
any device calibration tools. In a DeltaV environment, the asset management 
solutions (AMS) diagnostic tool manufactured and sold by Fisher-Rosemount can be 
used for this purpose to communicate with a device, to obtain specific information 
therewith and to implement diagnostics associated with the device. Of course, other 
tools or recommendations could be made as well. For example, for transmitter 
problems, or function blocks associated with transmitters, the block 94 may 
recommend that a device calibration be used to calibrate the transmitter while, for a 
valve, any of the valve diagnostic routines can be used to detect and possibly 
correct the specific problem within the valve. Generally speaking, the 
recommendations made by the block 94 may be determined based on whether the 
problem falls into one of a number of predetermined types of problems, the nature 
or identity of the source of the problem (e.g. whether it originated in a control or 
input function block, a transmitter or a valve, etc.) or any other desired criteria. Of 
course, any desired diagnostic tools can be used, including those now known or 
those developed in the future. 

If the specific nature of the problem is not easily detected from the 
variability, status, mode, limit or other data that pointed to the existence of a 
problem, the block 94 can recommend the use of other, more complex diagnostic 
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tools, such as plotting routines, correlation (such as auto-correlation and cross- 
correlation) routines, spectrum analysis routines, expert analysis routines or any 
other desired routine or tools provided for the process control system 10. Of 
course, the diagnostic tool 52 may recommend or suggest the use of more than one 
tool and allow the operator to choose which tool should be used in any situation. 
Furthermore, the block 94 may limit its suggestions to tools actually available 
within the process control network 10, e.g., those loaded onto the operator 
workstation 13, or may suggest tools that would have to be purchased or loaded into 
the process control system 10 before being used. Of course, the block 94 can also 
suggest the use of manual tools, i.e., those which are not run on the operator 
workstation 13, controller 12 or one of the devices 15-28. 

After the block 94 recommends one or more further diagnostic tools, a block 
96 waits for a user to select a tool for implementation, and, upon receiving such an 
instroction from the operator, a block 98 finds and executes the selected tool to 
15 enable the operator to further analyze and pinpoint the cause of the problem or to 
fix the problem. After implementing the diagnostic tool, a block 100 enables the 
operator to select a different tool for the selected problem and a block 102 enables 
the operator to select a different problem. 

In one embodiment, the block 94 can recommend analysis tools typically 
20 referred to as trending applications that require the collection of a relatively large 
amount and/or a lot of samples of data before being able to be run. Examples of 
such trending applications include a correlation analysis, a neural network, a fuzzy 
logic control procedure, an adaptive tuning procedure, a spectrum analysis routine, 
etc. Unfortunately, when the diagnostic tool 52 detects problems, the data required 
25 for the trending tool is typically unavailable because this data was not previously 
collected. This data may be needed to be collected at a high frequency data rate 
that is not practically achievable using simple communications between the 
controller 12 and the workstation 13. As a result, when the operator selects a tool 
that requires the collection of this data (fast data), the block 98 may automatically 
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configure the controller 12 to collect the necessary data from the process control 
system 10. 

When such data needs to be collected from Fieldbus function blocks or 
devices, i.e., from the devices via the Fieldbus bus, the controller 12 may use one 
5 or more Fieldbus trend objects to collect the data, may bundle and store the 
collected data as packets of data, and may then send the packets of data to the 
operator workstation 13 at any desired time so that the fast data is delivered to the 
operator workstation 13 in a non-time critical manner. This operation reduces the 
communication load between the controller 12 and the operator workstation 13 for 

10 the collection of this data. Typically, a trend object is set up to collect a 

predetermined number of samples (e.g., 16) of any desired data pertaining to a 
function block and, when the predetermined number of samples has been collected, 
these samples are communicated to the controller 12 using asynchronous 
communications. The use of one or more trend objects 110 for Fieldbus function 

15 blocks is illustrated in Fig. 8. The trend object(s) 110 are used to collect and send 
desired data to the data collection device 48 within the controller 12 and originate 
within the actual function blocks down within the Fieldbus devices. These trend 
objects 110 may be provided by the Fieldbus device or by the shadow function 
blocks (illustrated generally as shadow function blocks 112S in Fig. 8) within the 

20 controller 12. Similarly, for function blocks located within and executed by the 
controller 12 (illustrated generally as function blocks 113 in Fig. 8), virtual trend 
objects 114 can be set up within the controller 12 to collect the desired data 
delivered from the 4-20 ma (or other devices). Samples for such virtual trend 
objects 114 may be collected at any desired rate, such as every 50 milliseconds. 

25 The virtual trend objects 1 14 may be configured to be similar to the actual trend 
objects of the Fieldbus protocol and are delivered to the data collection device 48. 
The data collection device 48 delivers the collected data to the data historian 50 
within the operator workstation 13 as noted above. 

The trend objects 1 10 and 1 14 are collected until enough data has been 

30 stored to run the desired diagnostic tool. After enough fast data has been collected, 
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the block 98 of Fig. 4 executes or otherwise implements the further diagnostic tool ■ 
using the collected data so as to perform high level processing and loop analysis. 

While the diagnostic tool 52 has been described as being used in conjunction 
with Fieldbus and standard 4-20 ma devices, it can be implemented using any other 
5 external process control communication protocol and may be used with any other 
types of function blocks or devices having function blocks therein. Moreover, it is 
noted that the use of the expression "function block 1 * herein is not liihited to what 
the Fieldbus protocol or the DeltaV controller protocol identifies as a function block 
but, instead, includes any other type of block, program, hardware, firmware, etc., 

10 associated with any type of control system and/or communication protocol that can 
be used to implement some process control function. While function blocks 
typically take the form of objects within an object oriented programming 
environment, this need not be case. 

Although the diagnostic tool 52 described herein is preferably implemented 

15 in software, it may be implemented in hardware, firmware, etc., and may be 

implemented by any other processor associated with the process control system 10. 
Thus, the routine 60 described herein may be implemented in a standard multi- 
purpose CPU or on specifically designed hardware or firmware as desired. When 
implemented in software, the software routine may be stored in any computer 

20 readable memory such as on a magnetic disk, a laser disk, or other storage medium, 
in a RAM or ROM of a computer or processor, etc. Likewise, this software may 
be delivered to a user or a process control system via any known or desired delivery 
method including, for example, on a computer readable disk or other transportable 
computer storage mechanism or over a communication channel such as a telephone 

25 line, the internet, etc. (which are viewed as being the same as or interchangeable 
with providing such software via a transportable storage medium). 

Thus, while the present invention has been described with reference to 
specific examples, which are intended to be illustrative only and not to be limiting 
of the invention, it will be apparent to those of ordinary skill in the art that changes, 
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additions or deletions may be made to the disclosed embodiments without departing 
from the spirit and scope of the invention. 

In the present specification "comprise" means "includes or consists of 1 
and "comprising" means "including or consisting of. 

The features disclosed in the foregoing description, or the following 
claims, or the accompanying drawings, expressed in their specific forms or in 
terms of a means for performing the disclosed function, or a method or process 
for attaining the disclosed result, as appropriate, may, separately, or in any 
combination of such features, be utilised for realising the invention in diverse 
forms thereof. 
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CLAIMS 

Wfia; is claimed is: 

1 . A diagnostic tool for use in a process control system having a 
multiplicity of function blocks, the diagnostic tool comprising: 

a data collection unit configured to communicate with each of the 
multiplicity of function blocks to receive, on a regular basis during operation of the 
process control system, data pertaining to a function block operating parameter for 
each of the multiplicity of function blocks; 

a data analyzer that determines a value for the function block operating 
parameter for each of a number of times during operation of the process control 
system based on the received function block operating parameter data; 

a detector that detects a problem within the process control system based on 
the determined values of the function block operating parameter; and 

an output generator that creates a report indicating the detected problem. 

2. The diagnostic tool of claim 1, wherein the function block operating 
parameter is a variability parameter and wherein the data analyzer determines a 
variability value associated with one of the function blocks at each of the number of 
times based on the collected function block operating parameter data. 

3. The diagnostic tool of claim 2, wherein the detector compares the 
variability value with a variability limit to detect the problem. 

4. The diagnostic tool of claim 2, wherein the variability value is 
indicative of an integral squared error between a first function block parameter and 
a second function block parameter. 

5. The diagnostic tool of claim 4, wherein the first function block 
parameter is a statistical value of a process control parameter and the second 
function block parameter is an instantaneous value of the process control parameter. 
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6. The diagnostic tool of claim 2, wherein the one of the function 
blocks is associated with an input device that measures a process parameter and 
wherein the variability value for the one of the function blocks comprises an 
indication of an error between a statistical value of the measured process parameter 
and an instantaneous value of the measured process parameter. 

7. The diagnostic tool of claim 2, wherein the one of the function 
blocks uses a process parameter signal and a set point to produce a control signal 
and wherein the variability value for the one of the function blocks comprises an 
indication of an error between the process parameter and the set point. 

8. The diagnostic tool of claim 2, wherein the function block operating 
parameter data received from each of the function blocks includes a first variability 
indication indicative of a mean absolute error of a function block parameter and a 
second variability indication indicative of a moving range average of the function 
block parameter. 

9. The diagnostic tool of claim 2, wherein the function block operating 
parameter data received from each of the function blocks includes a first variability 
indication indicative of an actual total standard deviation of a function block 
parameter and a second variability indication indicative of a capability standard 
deviation associated with the function block parameter. 

10. The diagnostic tool of claim 9, wherein the data analyzer combines 
the first variability indication with the second variability indication to produce the 
variability value. 

1 1 . The diagnostic tool of claim 10, wherein the data analyzer adds a 
sensitivity value to each of the first and second variability indications to produce the 
variability value. 
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12. The diagnostic tool of claim 2, wherein the function block operating 
parameter data comprises the variability value. 



13. The diagnostic tool of claim 1 , wherein the function block operating 
parameter is a mode parameter and wherein the data collection unit receives a mode 
indication for each of the function blocks. 

14. The diagnostic tool of claim 13, wherein the data analyzer determines 
a mode value for one of the function blocks specifying if the one of the function 
blocks is in a normal mode in which the one of the function blocks was designed to 
operate during normal operation. 

15. The diagnostic tool of claim 13, wherein the data analyzer determines 
a mode value for one of the function blocks as a percentage of a specific period of 
time that the mode of the one of the function blocks was a non-normal mode 
associated with the one of the function blocks. 

16. The diagnostic tool of claim 15, wherein the detector compares the 
mode value for the one of the function blocks to a mode limit to detect the problem. 

17 . The diagnostic tool of claim 1 , wherein the function block operating 
parameter is a sums parameter and wherein the data collection unit receives status 
indications for each of the multiplicity of function blocks. 

18. The diagnostic tool of claim 17, wherein the data analyzer determines 
a status value from the status indications indicating if a status associated with one of 
the function blocks is a normal status associated with the normal operation of the 
one of the function blocks. 
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19. The diagnostic tool of claim 17, wherein the data analyzer determines 
a status value for one of the function blocks as a percentage of a specific period of 
time that the status of the one of the function blocks was a non-normal status 
associated with the one of the function blocks. 

20. The diagnostic tool of claim 19, wherein the detector compares the 
sums value for the one of the function blocks to a status limit to detect the problem., 

21 . The diagnostic tool of claim 1, wherein the function block operating 
parameter is limit parameter and the data collection unit collects limit indications 
associated with a function block variable. 

22. The diagnostic tool of claim 21, wherein the data analyzer determines 
a limit value from the limit indications indicating if the function block variable is at 
one or more limits. 

23. The diagnostic tool of claim 21, wherein the data analyzer determines 
a limit value as a percentage of a specific period of time that the function block 
variable was at one or more limits. 

24. The diagnostic tool of claim 1, wherein the data collection unit 
further collects an application state parameter from one of the multiplicity of 
function blocks and wherein the detector ignores the function block operating 
parameter data associated with the one of the multiplicity of function blocks to 
detect the problem when the function block operating parameter data is associated 
with a time in which the.application state parameter was in a First state and the 
detector uses the function block operating parameter data associated with the one of 
the multiplicity of function blocks to detect the problem when the function block 
operating parameter data is associated with a time in which the application state 
parameter was in a second state. 
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25 . The diagnostic tool of claim 1 , wherein the detector detects the 
problem based on a current value of the function block operating parameter for on 
of the multiplicity of function blocks. 

26. The diagnostic tool of claim 1, wherein the detector detects the 
5 problem based on a plurality of past values for the function block operating 

parameter for one of the function blocks. 

27. The diagnostic tool of claim 1, wherein the detector compares the 
value of the function block operating parameter to a preset limit and further 
including a communicator that enables the preset limit to be specified by a user. 

I o 28 . The diagnostic tool of claim 1 , wherein the detector detects the 

problem based on a plurality of values of the function block operating parameter 
over a particular time and further including a communicator that enables the 
particular time to be specified by a user. 

29. The diagnostic tool of claim 1, further including a recommendation 
15 unit that recommends use of a further tool to correct the detected problem. 

30. The diagnostic tool of claim 29, wherein the recommendation unit 
recommends the use of a tuner. 

31 . The diagnostic tool of claim 29, wherein the recommendation unit 
recommends the use of a calibrator. 

20 32. The diagnostic tool of claim 29, wherein the recommendation unit 

implements the recommended further tool. 

-38- 



33. The diagnostic tool of claim 29, wherein the further tool requires 
collection of process parameter data of a process parameter and further including a 
further data collection unit that automatically collects samples of the process 
parameter as the process parameter data using a trend object during operation of the 
process control system. 

34. The diagnostic tool of claim 33, wherein the trend object is a virtual 
trend object created by the further data collection unit. 

35. The diagnostic tool of claim 33, wherein the trend object is created 
by one of the function blocks. 

36. A diagnostic tool for use in a process control system that includes a 
processor and that uses a multiplicity of function blocks to control a process, the 
diagnostic tool comprising: 

a computer readable memory; and 

a routine stored on the computer readable memory and adapted to be 
implemented on the processor, wherein the routine; 

collects data pertaining to a function block operating parameter for 
each of the multiplicity of function blocks on a regular basis during 
operation of the process; 

determines a value for the function block operating parameter for 
each of a number of times during the operation of the process control system 
based on the collected function block operating parameter data; 

detects a problem within the process control system based on the 
determined values of the function block operating parameter; and 

produces a report that lists the detected problem. 
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37. The diagnostic tool of claim 36, wherein the function block operating 
' parameter is a variability parameter and wherein the routine collects variability 

indications for each of the multiplicity of function blocks. 

38. The diagnostic tool of claim 37, wherein the routine determines a 
5 variability value for one of the fiinction blocks from the variability indications 

collected from the one of the function blocks and compares the variability value to a 
variability limit to detect the problem. 

39. The diagnostic tool of claim 36, wherein the function block operating 
parameter is a mode parameter and wherein the routine collects mode indications 

1 0 for each of the multiplicity of function blocks. 

40. The diagnostic tool of claim 39, wherein the routine determines a 
mode value for one of the function blocks as a percentage of a specific period of 
time that the one of the function blocks was in a non-normal mode associated with 
the one of the function blocks. 

15 41 . The diagnostic tool of claim 36. wherein the function block operating 

parameter is a status parameter and wherein the routine collects status indications 
for each of the multiplicity of function blocks. 

42 . The diagnostic tool of claim 41 , wherein the routine determines a 
status value for one of the function blocks as a percentage of a specific period of 

20 time that a status associated with the one of the function blocks was a non-normal 
status. 

43 . The diagnostic tool of claim 36, wherein the function block operating 
parameter is limit parameter and the routine collects limit indications associated 
with a function block variable. 
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44. The diagnostic tool of claim 43, wherein the routine determines a 
limit value from the limit indications as a percentage of a specific period of time 
that the function block variable was at one or more limits. 

45. The diagnostic tool of claim 36, wherein the routine further collects 
an application state parameter from one of the multiplicity of function blocks and 
ignores the function block operating parameter data associated with the one of the 
multiplicity of function blocks to detect the problem when the function block 
operating parameter data is associated with a time in which the application state 
parameter was in a first state and uses the function block operating parameter data 
associated with the one of the multiplicity of function blocks to detect the problem 
when the function block operating parameter data is associated with a time in which 
the application state parameter was in a second state. 

46. The diagnostic tool of claim 36, wherein the routine detects the 
problem based on a multiplicity of historical values of the function block operating 

15 parameter for one of the multiplicity of function blocks. 

47. The diagnostic tool of claim 36, wherein the routine recommends the 
use of a further tool to correct the detected problem. 

48. The diagnostic tool of claim 47, wherein the routine recommends one 
of a tuner routine, a calibration routine and a data analysis routine as the further 

20 tool. 

49. The diagnostic tool of claim 47, wherein the routine implements the 
recommended further tool. 
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50. The diagnostic tool of claim 47, wherein the routine recommends the . 
use of a further tool that requires the collection of process parameter data for a 
process parameter and automatically collects samples of the process parameter as 
the process parameter data during operation of the process control system. 

51 . A method of diagnosing problems in a process control system that 
uses a multiplicity of function blocks to control the operation of a process, the 
method comprising the steps of: 

collecting data pertaining to a ftmction block operating parameter from each 
of the multiplicity of function blocks during operation of the process control system; 

determining a value for the function block operating parameter for each of a 
number of times during operation of the process control system based on the 
received function block operating parameter data; 

detecting a problem within the process control system based on the 
determined function block operating parameter values; and 

reporting the detected problem to a user 

52. The method of claim 51 , wherein the function block operating 
parameter is a variability parameter and the step of collecting data includes the step 
of collecting variability indications for each of the multiplicity of function blocks. 

53. The method of claim 52, further including the step of calculating first 
and second variability indications in each of the function blocks as the function 
block operating parameter data, wherein the step of collecting includes the step of 
sending the first and second variability indications from each of the function blocks 
to a data analyzer and further including the step of calculating a value of the 
variability parameter for each of the function blocks in the data analyzer. 
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54. The method of claim 51 , wherein the function block operating 
parameter is a mode parameter and the step of collecting data includes the step of 
collecting mode indications for each of the multiplicity of function blocks. 

55. The method of claim 54, wherein the step of determining includes the 
step of determining a mode value for one of the function blocks as a percentage of a 
specific period of time that the one of the function blocks was in one of a normal or 
a non-normal mode associated with the operation of the one of the function blocks 
and the step of detecting includes the step of comparing the mode value for the one 
of the function blocks to a mode limit. 

56. The method of claim 51, wherein the function block operating 
parameter is a status parameter and the step of collecting data includes the step of 
collecting status indications for each of the multiplicity of function blocks. 

57. The method of claim 56, wherein the step of determining includes the 
step of determining a status value for one of the function blocks as a percentage of a 
specific period of time that the status of the one of the function blocks was one of a 
normal status or a non-normal sums associated with the one of the function blocks 
and the step of detecting includes the step of comparing the status value for the one 
of the function blocks to a status limit. 

58. The method of claim 51, wherein the function block operating 
parameter is a limit parameter related to whether a function block variable is at one 
or more limits and the step of collecting data includes the step of collecting limit 
indications for each of the multiplicity of function blocks. 
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59. The method of claim 58, wherein the step of determining includes the 
step of determining a limit for one of the function blocks as a percentage of a 
specific period of time that the function block variable is at the one or more limits 
and the step of detecting includes the step of comparing the limit value for the one 
of the function blocks to a limit value limit. 

60. The method of claim 51 , further including the step of collecting an 
application state parameter from one of the multiplicity of function blocks and 
wherein the step of detecting includes the steps of ignoring the function block 
operating parameter data associated with the one of the multiplicity of function 
blocks to detect the problem when the function block operating parameter data is 
associated with a time in which the application state parameter was in a first state 
and using the function block operating parameter data associated with the one of the 
multiplicity of function blocks to detect the problem when the function block 
operating parameter data is associated with a time in which the application state 
parameter was in a second state. 

61. The method of claim 51, further including the step of automatically 
recommending the use of a further tool to correct the one or more detected 
problems. 

62. The method of claim 61 , further including the step of automatically 
collecting process parameter data during operation of the process control system for 
use by the further recommended tool. 
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63. A function block for execution by a processor in a process control 
environment, comprising: 

a computer readable memory; 

a first routine stored on the computer readable memory and adapted to be 
executed on the processor to implement a process operation, wherein a first signal 
is associated with an operation of the first routine; and 

a second routine stored on the computer readable memory and adapted to be 
executed on the processor to determine a variability indication based on the first 
signal. 

64. The function block of claim 63, wherein the function block is an 
input function block, the first signal is indicative of a process parameter 
measurement and wherein the second routine compares a statistical measurement of 
the first signal to an instantaneous measurement of the first signal to determine the 
variability indication. 

65. The function block of claim 64, wherein the statistical measurement 
of the first signal is a mean. 

66. The function block of claim 63, wherein the function block is a 
control function block that uses a process parameter signal and a set point to 
produce a control signal and wherein the second routine compares the process 
parameter signal and the set point to determine the variability indication. 

67. The function block of claim 63, wherein the variability indication is 
indicative of the integral squared error between the first signal and another value 
associated with the function block. 
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68. The function block of claim 63, wherein the second routine calculates 
value for the variability indication after each of a plurality of executions of 



a new 
the first routine 



69. The function block of claim 63 , wherein the variability indication is 
based on a calculation of the mean absolute error of the first signal. 

70. The function block of claim 63, wherein the variability indication is 
based on a calculation of a moving range average associated with the first signal. 

71 . The function block of claim 63, wherein the variability indication 
includes a first value representing a mean absolute error of first signal and a second 
value representing a moving range average of the first signal. 

72 . The function block of claim 63 , wherein the variability indication 
includes a first variability value indicative of an actual total standard deviation 
associated with the first signal and a second variability value indicative of a 
capability standard deviation associated with the first signal. 

73 . The function block of claim 63 , wherein the variability indication (V) 
is computed as 



s *s 
S *s 

cor 



wherein ^ is a minimum standard deviation expected with feedback control, S l01 is 
an actual measured standard deviation and s is a sensitivity factor. 

74. The function block of claim 63, wherein the function block is a 
Fieldbus function block and includes a communication unit that communicates the 
variability indication over a Fieldbus bus using a Fieldbus protocol. 
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75. A function block for execution on a processor as part of a process 
control application within a process control environment, comprising: 

a computer readable memory; 

a first routine stored on the computer readable memory and adapted to be 
5 executed on the processor to implement a process operation as part of the process 
control application; and 

a state variable that is set to a first state when the process control application 
is using the function block in an attempt to perform the process operation and is set 
to a second state when the process control application is not using the function 
10 block in an attempt to perform the process operation. 

76. The function block of claim 75. wherein the function block is a 
Fieldbus function block and includes a communication unit that communicates the 
state variable over a Fieldbus bus usine a Fieldbus protocol. 

77. Any novef feature or novel combination of features described 
herein and/or in the accompanying drawings. 
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